A procurement agent is a user (e.g., a real person or a computer-implemented surrogate) serving to manage processes between a buying and selling organization. As used in this paragraph, a procurement agent acts on behalf of a buying organization, for example, to procure goods or services from a supplier; or, a procurement agent acts on behalf of a selling organization. Typically, the procurement agents' duties include identifying savings opportunities, determining negotiation strategies, creating sourcing events, awarding future business (e.g., in the form of contracts or purchase orders to suppliers), administering procurement contracts, evaluating and qualifying of the supply base, administering catalog content, and managing the transactional aspects of the procurement process. Sample job titles that a procurement agent may have within an organization include “Buyer”, “Procurement Manager”, “Category Manager”, “Procurement Contracts Administrator”, “Supplier Administrator”, and “Catalog Administrator”. Regardless of any assigned title, a procurement agent may take on a role (or sometimes multiple roles) to perform any one or more of the aforementioned services within an enterprise and, in the fulfillment of such a role, a procurement agent typically uses one or more procurement applications in the performance of such services.
Most procurement applications are delivered as one or more software modules running on commodity (or custom) hardware computing platforms, and most have a mechanism to define duties (e.g., process purchase orders, negotiate contracts, etc.) and/or roles (e.g., a role of buyer, seller, administrator, agent). In some cases a procurement application can be configured to provide access to documents used for communication within the enterprise and between buyers and sellers. Sometimes access to a document is shared within the enterprise and between buyers and sellers using an electronic exchange. And, in some cases, a procurement application can be configured to provide shared access to documents based on coarse definitions of document access (e.g., corresponding to a hierarchy). In some situations, coarse definitions of document access can suffice, however as the complexity of interactions within and between enterprises grows, so does the complexity of managing shared access.
Legacy procurement applications lack the ability to define a robust and flexible list of roles and duties that addresses the complexity of the interactions within and between the aforementioned enterprises.
Such deficiencies are often exacerbated in the sense that modern enterprises have a hierarchical reporting structure that includes ‘junior agents’ whose work is performed at the direction of more senior agents. Thus, it is possible that the more senior agents may have a need to access (e.g., to view, to edit, etc.) the documents of a junior agent. In such a scenario it is reasonable to give full access to the more senior agent for accessing the junior agent's documents, while concurrently restricting accesses to the junior agent's documents by other junior agents. However, legacy implementations fail to provide techniques to define and enforce permissible actions that an agent (e.g., a particular junior agent, or a more senior agent) can perform on documents.
As used herein, procurement refers to the acquisition of goods and/or services for the benefit of or use by entities (e.g., business units) in an enterprise. Procurement requisitions (e.g., requests to purchase raw materials, office supplies, capital equipment, etc.) are typically generated by many business units in an enterprise. While it is advantageous to establish multiple (e.g., primary and backup) procurement service providers (e.g., procurement agents) in an enterprise, each of whom are specifically adapted to perform some or all of these procurement activities on behalf of procurement clients, not all procurement agents have a need-to-know for all information regarding another procurement agent's activities. And in fact, some certain set of a procurement agent's documents (e.g., documents underlying the activities) should be restricted from access by other procurement agents.
What is needed are techniques to address the deficiencies of the legacy solutions and, more specifically, to address document security deficiencies by providing techniques to define and enforce permissible actions that an agent can perform to a document.